home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19950929-19951130 / 000235_news@columbia.edu_Sun Oct 29 11:47:29 1995.msg < prev    next >
Internet Message Format  |  1995-12-25  |  3KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA08846
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 29 Oct 1995 20:47:09 -0500
  3. Received: by apakabar.cc.columbia.edu id AA25559
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 29 Oct 1995 20:46:57 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!news.uoregon.edu!usenet.eel.ufl.edu!newsfeed.internetmci.com!chi-news.cic.net!uwm.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Maximum transfer speed
  9. Message-Id: <1995Oct29.174729.65311@cc.usu.edu>
  10. Date: 29 Oct 95 17:47:29 MDT
  11. References: <Pine.HPP.3.91.951029001618.14977A-100000@bluejay.creighton.edu>
  12. Organization: Utah State University
  13. Lines: 40
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <Pine.HPP.3.91.951029001618.14977A-100000@bluejay.creighton.edu>, Psychos 'R Us <honge@creighton.edu> writes:
  17. > This may have asked numerous times but I need the info pretty bad.
  18. > 
  19. > I'm trying to download Big Files from a HP server. The Y-modem-G was not 
  20. > robust enough, and Z-modem has some problem working out. Basically the 
  21. > I'm logging into the HP server as a dumb terminal. Both the HP-UX kermit 
  22. > and the OS/2 kermit (on my end) are 5A(191). But for some reason, I 
  23. > cannot break through the 1041cps barrier. Using the Y-modem-G, the 
  24. > maximum transfer is at 1681cps. The modems (a Hayes Accura 14.4 and a 
  25. > Cardinal 14.4) operate at 14.4bps. On the average, I get one transfer 
  26. > error every 10 minutes (that's mathmatical average -- the real stuff is 
  27. > quite random but the phone noise is there).
  28. > 
  29. > On the HP-UX end, the only thing I do is "kermit -i -x." On the OS/2 end, 
  30. > I have set packet size to 2048, window slots to 24, and everything else 
  31. > is as-is. 
  32. > 
  33. > Is there any other things I can/should do? I tried to use MS-Kermit 
  34. > (MS-DOS version). On that one, I couldn't even raise the packet length 
  35. > beyond 371! Oh well...
  36. ------------
  37.     Your last paragraph contains a useful piece of information. A
  38. packet length of 371 bytes is not the kind of number we normally choose
  39. for packets, but it is the kind of number which arises when a packet is
  40. dinged and the sending side shrinks them upon retries. That's the "rubber
  41. packet" heuristic.
  42.     In most cases of this kind our first response is "flow control,
  43. flow control!" For best flow control use hardware RTS/CTS between your
  44. machine and the modem, expect the modems to do their modem to modem
  45. flow control under V.everything, and cross your fingers that your remote
  46. host does snappy flow control with its modem too. Flow control must be
  47. carried through from end to end, else traffic jams yield lost bytes.
  48.     The second response is, maybe there is a terminal server or other
  49. comms box between you and the host and it is unable to handle fast traffic
  50. without dropping bytes. Terminal servers are often quite wierd boxes.
  51.     The third and usually last blind suggestion is ensure your OS/2
  52. end has a decent serial port, typically a 16550A UART, so it does not 
  53. drop bytes under load.
  54.         Hopefully in this list will be something which applies.
  55.     Joe D.